27.2 Lokalisierung von Programmen  
Soll ein Programm nicht nur in einer Sprache, sondern in mehreren Sprachen weitergegeben werden, spricht man von Lokalisierung. Bei einer lokalisierten Anwendung werden zum Beispiel alle Zeichenfolgen in der Sprache ausgegeben, die der Landessprache des installierten Systems entspricht. Lokalisierte Anwendungen sind aber nicht nur in der Lage, landessprachlich spezifische Zeichenfolgen auszugeben, sondern können auch das Layout einer Benutzeroberfläche gestalten. Stellen Sie sich dazu nur vor, dass Sie eine Schaltfläche in deutscher Sprache beschriften, die Übersetzung des Textes in eine andere Sprache aber über die Breite der Schaltfläche hinausgehen würde und nicht mehr vollständig angezeigt werden könnte. .NET löst dieses Problem auf recht einfache Art und Weise.
Die Lokalisierung einer Anwendung lässt sich durch zwei Arbeitsschritte beschreiben:
| 1. |
Im ersten Schritt werden die Elemente der Benutzeroberfläche lokalisiert. Dazu kann der Text in der Titelleiste einer Form ebenso gehören wie die Beschriftung einer Schaltfläche sowie die Anpassung der Benutzeroberfläche an die lokalisierten Gegebenheiten. |
| |
|
| 2. |
Im zweiten Schritt wird der Programmcode berücksichtigt, damit auch die codierten Meldungen in der Landessprache ausgegeben werden. |
| |
|
27.2.1 Lokalisierung von Komponenten 
Die Eigenschaften »Localizable« und »Language«
Der Weg zu einer lokalisierten Windows-Anwendung führt über die Eigenschaften Localizable und Language, die im Eigenschaftsfenster der Form angezeigt werden, aber keine Mitglieder der Klasse Form sind, sondern vielmehr von der Entwicklungsumgebung zur Unterstützung der Entwicklungsarbeit eingeblendet werden.
Soll die Form lokalisiert werden, müssen Sie
Localizable = True
setzen. Das hat eine wichtige Konsequenz, denn infolgedessen wird eine Reihe von Einstellungen, beispielsweise die Beschriftung in der Titelleiste einer Form, die Beschriftung einer Schaltfläche und darüber hinaus auch deren Position, in einer Ressourcendatei gespeichert. Der Name der Ressourcendatei entspricht dem Namen der Quellcodedatei, hat allerdings die Dateiendung .RESX. Lautet die Datei Form1.vb, ist der Name des Ressourcendatei Form1.resx. Jedem Formmodul ist eine eigene Ressourcendatei zugeordnet, die automatisch von der Entwicklungsumgebung erzeugt wird.
Die zweite ausschlaggebende Eigenschaft ist Language, deren Vorgabe Standard ist, aber aus einer langen Liste auch anders festgelegt werden kann. Insbesondere wenn Sie nicht mit einem englischsprachigen System arbeiten, sollten Sie der Standardeinstellung besondere Aufmerksamkeit widmen. Lokalisieren Sie Ihre Anwendung beispielsweise in englischer und italienischer Sprache, während Sie in der Standardvorgabe die deutsche Sprache benutzen, wird der Anwender, der eine andere Landessprache als die drei genannten einsetzt, mit einer Anwendung in der Landessprache überrascht, die der Standardvorgabe entspricht – also in Deutsch. Wie Sie dieses Problem lösen können und Ihre Anwendung in der weltweit geläufigsten Sprache, in Englisch, ausliefern können, werden Sie gleich noch erfahren.
Die Ressourcendateien
Um sich die Ressourcendateien in der Entwicklungsumgebung anzeigen zu lassen, klicken Sie in der Symbolleiste des Projektmappen-Explorers auf Alle Dateien anzeigen. Die RESX-Dateien sind als Elemente des Knotens der Form-Datei untergeordnet. Wie könnte es anders sein, natürlich wird auch eine Ressourcendatei durch eine XML-Notation beschrieben.
Hier klicken, um das Bild zu Vergrößern
Abbildung 27.6 Der Editor einer Ressourcendatei
Ein Programmbeispiel
Wir wollen nun anhand eines kleinen Beispielprogramms die Lokalisierung einer Anwendung studieren. Dabei sei angenommen, dass auf einem deutschsprachigen System entwickelt wird und das Programm darüber hinaus auch noch in Englisch und Italienisch ausgeliefert werden soll. Weil die Standardsprache Englisch sein soll, stellen wir zunächst die Eigenschaft Language auf Deutsch ein.
| Hinweis
|
|
Um sich später bei der Entwicklung einer lokalisierten Anwendung nicht zu »verzetteln«, sollten die beiden Eigenschaften Localizable und Language festgelegt werden, bevor Sie mit der Programmierung beginnen.
|
Die Form soll eine Schaltfläche enthalten. Das Ziel, das wir mit diesem Beispiel anstreben, ist die sprachspezifische Ausgabe des Titelleistentextes und der Beschriftung der Schaltfläche. Da in der Eigenschaft Language=Deutsch eingestellt ist, können wir im Eigenschaftsfenster nun die Eigenschaft Text der Form (»Guten Morgen«) und der Schaltfläche (»Hier klicken«) festlegen.
Im nächsten Schritt soll die italienische Sprachversion berücksichtigt werden. Dazu wird Language auf Italienisch gesetzt. Tragen Sie nun die entsprechende italienische Übersetzung in den Text-Eigenschaften ein (»Buongiorno« und »Prema qui«). Dabei brauchen Sie sich nicht davon irritieren zu lassen, dass Ihnen zunächst andere Einträge angezeigt werden. Im letzten Schritt wählen Sie Language=(Standard). Die weitere Prozedur ist wie zuvor, jedoch in englischer Sprache (»Good morning« und »Click here«).
Über diese Einstellungen hinaus sollten Sie aus Demonstrationsgründen noch einmal unter Language die italienische Sprachversion einstellen und die Schaltfläche deutlich erkennbar vergrößern. Anschließend können Sie das Projekt speichern und ausführen. In Abhängigkeit vom installierten System erhalten Sie dann die entsprechende Sprachausgabe. Angenommen, Sie hätten eine japanische Version installiert, würden die Beschriftungen in Englisch angezeigt, weil diese Sprache als Standard festgelegt worden ist.
Wenn Sie einen Blick in den Projektmappen-Explorer werfen, werden Sie feststellen, dass für jede Einstellung unter Language eine weitere Ressourcendatei zum Projekt hinzugefügt worden ist, in deren Bezeichner auch eine Sprachkennung eingebaut ist (siehe Abbildung 27.7). Die Ressourcendatei ohne Sprachkennung dient der Standardeinstellung, die Datei Form1.it.resx speichert die italienischen Ressourcen, die Datei Form1.de.resx die deutschen. Im Windows Explorer ist zu sehen, dass die spezifischen Ressourcendateien deutlich kleiner sind als die der Standardeinstellung. Das hängt damit zusammen, dass die spezifischen Ressourcendateien nur die Abweichungen von der Datei enthalten, welche die Standardangaben abgespeichert hat.
Hier klicken, um das Bild zu Vergrößern
Abbildung 27.7 Die Ressourcendateien einer lokalisierten Form
Beim Wechsel in das Ausgabeverzeichnis der kompilierten Dateien machen wir noch eine weitere interessante Entdeckung: Für jede sprachspezifische Lokalisierung wird ein eigener Unterordner angelegt, der den Bezeichner der .NET-Sprachkennung hat, in unserem Beispiel »de« für Deutschland und »it« für Italien. In diesen Ordnern sind die lokalisierten Ressourcen als DLL-Dateien abgelegt. Die Einstellungen der Standardsprache werden direkt in die EXE-Datei kompiliert.
Testen der Lokalisierungen
Starten wir eine lokalisierte Anwendung, wird automatisch die Landeseinstellung des Betriebssystems verwendet. Ist die Anwendung nicht in der entsprechenden Sprachversion lokalisiert, wird die Sprache der Standardeinstellung der Eigenschaft Language benutzt.
Natürlich wollen wir auch alle Lokalisierungen testen. Hier hilft uns My.Application mit der Methode CurrentUICulture weiter, der wir für die zu testende Sprache ein Landeskürzel übergeben. Wollen wir die englische Lokalisierung testen, lautet das Kürzel »en«, für die italienische Lokalisierung »it«, für die deutsche »de«. Die Änderung muss vor dem Aufruf der Methode InitializeComponent im Konstruktor erfolgen:
| Public Sub New()
|
| My.Application.ChangeUICulture("it")
|
| InitializeComponent()
|
| End Sub
|
Wollen Sie darüber hinaus auch die englische bzw. deutsche Lokalisierung prüfen, brauchen Sie nur das Kürzel auszutauschen. Vor dem Verteilen der Anwendung müssen Sie natürlich die Anweisung wieder löschen. Wollen Sie über die Anpassung der Landessprache hinaus auch Datums- und Zeitangaben berücksichtigen, müssen Sie die Methode ChangeCulture ausführen. In der Zeichenkette wird über die Landessprache hinaus auch die jeweilige Landeseinstellung berücksichtigt, z. B. »en-GB« für Englisch in Großbritannien und »en-US« für Englisch in den USA.
Wie das entsprechende Kürzel lautet, können Sie der Dokumentation der Klasse CultureInfo entnehmen.
27.2.2 Zusätzliche Lokalisierungsdateien
Die bisher besprochenen Ressourcendateien sind nur in der Lage, bestimmte Eigenschaften der Komponenten zu lokalisieren. Wollen Sie aber beispielsweise in einem Meldungsfenster einen Text ausgeben, müssen Sie dem Projekt zusätzliche Ressourcendateien hinzufügen, um auch diese Meldungen in der landesspezifischen Sprache anzuzeigen. Das Hinzufügen geht wieder über das Kontextmenü des Projekts. Wählen Sie Hinzufügen und dann Neues Element ..., und wählen Sie die Vorlage Ressourcendatei. Unser Beispielprogramm LocalizedWinApp wollen wir in drei Landessprachen weitergeben, also benötigen wir auch drei zusätzliche Ressourcendateien. Bei der Vergabe der Dateinamen sollten wir darauf achten, die Konvention einzuhalten. Das heißt, alle drei Dateien müssen gleich benannt werden und die Dateiendung .RESX haben. Die Ressourcendateien der Sprachen, die nicht der Standardvorgabe entsprechen, werden zwischen dem Bezeichner und der Dateiendung um das Landeskürzel ergänzt. Somit könnten für unser Projekt die Namen MyResource.resx, MyResource.de.resx und MyResource.it.resx lauten.
Hier klicken, um das Bild zu Vergrößern
Abbildung 27.8 Die Projektdateien des Beispielprogramms »LocalizedWinApp«
Nehmen wir an, dass mit dem Klicken auf die Schaltfläche in der Form ein Meldungsfenster angezeigt werden soll. Der Meldungstext soll aus der Variablen strMeldung bezogen werden und muss natürlich lokalisiert sein. Dazu öffnen wir die entsprechende Ressourcendatei in der Entwicklungsumgebung und tragen den Inhalt von strMeldung, wie in der Abbildung 27.9 zu sehen ist, ein. Obwohl in der Abbildung nur eine Variable, die übrigens im Code nicht deklariert werden muss, eingetragen ist, werden in jeder Ressourcendatei alle lokalisierten Angaben gemacht, die zur Laufzeit sprachspezifisch ausgegeben werden müssen.
Hier klicken, um das Bild zu Vergrößern
Abbildung 27.9 Eintrag in eine benutzerdefinierte Ressourcendatei
Der Zugriff auf die in den Ressourcendateien gespeicherten Zeichenfolgen erfolgt am einfachsten über:
My.Resources.<Dateiname>.<Zeichenfolgenbezeichner>
Im Click-Ereignishandler der Schaltfläche sieht der Code dann wie folgt aus:
| Private Sub Button1_Click(...) Handles Button1.Click
|
| MessageBox.Show(My.Resources.MyResource.strMeldung)
|
| End Sub
|
Den vollständigen Code des Beispielprogramms finden Sie auf der Buch-CD unter \Kapitel 27\LocalizedWinApp.
| Tipp
|
|
Insbesondere wenn sehr viele Zeichenfolgen lokalisiert werden müssen, ist es sehr mühevoll, jeden Bezeichner in jeder gewünschten Ressourcendatei neu einzutragen – ganz abgesehen vom damit verbundenen Fehlerpotenzial. Sie können es sich aber sehr einfach machen, indem Sie die Bezeichner nur in eine Ressourcendatei eintragen und diese anschließend mit einem Editor öffnen (benutzen Sie hierzu das Kontextmenü der entsprechenden Datei im Projektmappen-Explorer). Sie erkennen dann, dass eine Ressourcendatei nichts anderes als eine XML-Datei ist, in der die Bezeichner der Ressourcen samt deren Werte eingetragen sind. Kopieren Sie das XML einfach in die XML-Datei einer anderen Lokalisierung. Danach brauchen Sie nur noch die Werte anzupassen.
|
|
